I don't understand why this works and how it fixes the issue.
The LookAheadMacroDefinition are inserted for all macro definitions, regardless of whether it's macro or macro_rules, and nothing is done for use items.
The reversed rib walk in fn apply_pattern_bindings can also encounter arbitrary ribs before encountering a LookAheadMacroDefinition.

Also "shallow" -> "shadow" in the PR/commit messages and file names.

The reversed rib walk in fn apply_pattern_bindings can also encounter arbitrary ribs before encountering a LookAheadMacroDefinition.

There may be a bug if LookAheadMacroDefinition fails to apply correctly.

I don't understand why this works and how it fixes the issue.

LookAheadMacroDefinition stores the macro expansion result and serves as a fallback in resolve_ident_in_lexical_scope, ensuring it takes the correct resolution path:

@rustbot ready

@bvanjoi
Are you sure this cannot successfully resolve some names that should not be resolved?
(I started reviewing yesterday, but it was late so I'll finish today or on Monday.)

Are you sure this cannot successfully resolve some names that should not be resolved?

I need to test this with additional cases across different rib contexts. @rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

This PR was rebased onto a different master commit! Check out the changes with our range-diff.

Technically it should do that even if m is exported from a different crate

These changes have wide-ranging implications. Could you please review whether the modifications in tests/ui/hygiene/{legacy_interaction, wrap_unhygienic_example}.rs produce the expected behavior?

Reduce for #143141 (comment)

macro_rules! m2 {
    () => {{
        static B: i32 = S;
        42
    }};
}

macro_rules! m {
    () => {
        static S: i32 = m2!();
    };
}

fn main() {
    m!();
}

Using lexical scope at macro definition sites presents problematic outcomes:

1. ​If we adopt this behavior:​​ Risk significant regression, including failure to compile stage2 of the compiler due to tracing crate failures. Additional affected cases exist in tests/ui/hygiene/{wrap_unhygienic_example, legacy_interaction}.rs.

2. ​If we reject this behavior:​​ The example from fresh binding should shadow the def in expand #143141 (comment) would compile successfully, which contradicts previous discussion.

This behavior is related to the changes: https://github.com/rust-lang/rust/pull/143141/files#diff-c046507afdba3b0705638f53fffa156cbad72ed17aa01d96d7bd1cc10b8d9bceR454-R483

What do you think? Should we introduce this change as a lint instead? @petrochenkov

Should we introduce this change as a lint instead?

We'll definitely need a crater run and possibly a lint in the end.

But at this point we probably rather need some more or less formal model of the rules that we want to achieve.
At both call site (including code coming from the macro itself) and at def site local variables and items can interleave, so it needs to be clarified what are the priorities.
I.e. what is the search order here.

#![allow(unused)]

fn f() {
    let a = 0;
    {
        fn a() {}
        {
            let a = 0;
            {
                fn a() {}
                
                #[macro_export]
                macro_rules! mac {
                    () => {
                        let a = 0;
                        {
                            fn a() {}
                            {
                                let a = 0;
                                {
                                    a; // use
                                }
                            }
                        }
                    };
                }
            }
        }
    }
}

fn main() {
    let a = 0;
    {
        fn a() {}
        {
            let a = 0;
            {
                mac!();
            }
        }
    }
}

But at this point we probably rather need some more or less formal model of the rules that we want to achieve.

Have there been any mathematical models proposed, such as proof trees in type theory, to formally describe macro expansion? I've never encountered.😂

@bvanjoi
https://www-old.cs.utah.edu/plt/scope-sets
That's what macros 2.0 hygiene is inspired by as well.

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

what is the search order here.

I will try to answer this after reading this book.

@rustbot ready